A Service Oriented Architecture (SOA) is a business-driven IT architectural approach that supports integrating the business as linked, repeatable business tasks, or services. The basic building block is a service document that defines a service so that it can be managed with other services. A service document contains information about a service including the location of the service and details about the service and how to access the service. Service documents are used by analysts, architects, and developers during a development phase of the SOA lifecycle to locate services to reuse and to evaluate the impact of changes to service configurations. Service documents are variously described as metadata, objects, descriptions, entities and artifacts.
A service repository stores the service document and allows access to the service document and thereby the corresponding service. A service registry is an index of a subset of information about a service (for example the location and name of service document) enabling the corresponding service document to be located and accessed in a repository (or even the corresponding service located at the service provider). An integrated service registry and repository allows a service operation to use both the indexed service information in the registry and the detailed service information in the repository. An example of an integrated service registry and repository is IBM® WebSphere® Registry and Repository (WSRR).
Such an integrated service registry and repository has advantages of greater business agility and resilience through reuse than separate systems. Further advantages of looser coupling, greater flexibility, better interoperability, and better governance arise from the integration. These advantages are addressed by separating service descriptions from their implementations, and using the service descriptions across the lifecycle of the service. Standards-based service metadata artifacts, such as Web Service Definition Language (WSDL), Extensible Mark-up Language (XML) schema, policy or Service Component Architecture (SCA) documents, capture the technical details of what a service can do, how it can be invoked, or what it expects other services to do. Semantic annotations and other metadata can be associated with these artifacts to offer insight to potential users of the service on how and when it can be used, and what purpose it serves.
A policy is a rule that is applied to an object by an environment. For instance, access to an object can be controlled by applying a rule that only entities with a certain token can have access to the object. W3C (World Wide Web Consortium) is a community working together to develop interoperable internet technology. WS-Policy is a W3C WS (Web Service) standard that is intended to provide a means for specifying policies that need to be applied to web services and specifically service documents. A policy can be a generic policy as defined in the WS-Policy framework or it can be a domain specific policy as defined in a policy domain. The WS-Policy-Attach specification (also controlled by the W3C) specifies a standard means by which policy attachments can be defined to link a policy to a service object referenced in a service document.
Service objects or logical objects are derived from documents (WSDL (Web Service Definition Language) documents; XSD (XML schema definition) documents; XML (extensible mark-up language) documents, WS-Policy documents etc.) when they are loaded into the service registry environment. The WS-Policy-Attach specification declares different means of specifying policy attachments that link specific policies to target subjects: embedded policies in WSDL documents; embedded policy references in WSDL documents; embedded policy references from policyURI (Universal Resource Indicator) attributes in WSDL documents; embedded policies in external policy attachment files; and embedded policy references in external policy attachment files.
These service or logical objects can be transitioned through states defined in a lifecycle (e.g., assemble, deploy, manage, retire), and the resulting states will be reflected in the classification metadata associated with these objects. The service registry console or Application Programming Interfaces (APIs) can be used to locate and use the objects based upon these classifications.
Lifecycle definitions for these objects in the service registry are defined by a standard representation called State Adaptive Choreography Language (SACL). While a SACL infrastructure to manage the lifecycle of objects in the service registry gives a flexible framework to represent objects with states and transitions, it lacks the ability to pictorially present to end users information about the current lifecycle state, next lifecycle states, possible transitions and constraints represented as policy assertions on the transitions (e.g., WS-Policy assertions). That is, the current representation of lifecycle states in SACL and policies are in a disjoint and disconnected manner thereby making it difficult for the end user to predict the next possible lifecycle states as well as the policies that apply to each next possible transition.